Software Engineers do not Need to Become Managers to Thrive
Though the title of this post may sound obvious to some, it’s not how most organizations function. Many excellent software engineers are led to believe that the only way they can progress in their career is to eventually manage people and teams.
I have my own theories as to why this is the case. In many fields, the desire to move into management has historically been driven by substantially higher salary and status. Though those things can be true in engineering, they tend not to be among actual engineers. For many engineers there’s higher status (and even pay!) in building great software. So what’s going on?
The Career Ladder
Despite how you feel about the concept of a “career ladder”, it’s hard to avoid thinking of your career as a series of steps in an upward direction. First you’re an intern, then a full-time junior engineer trying to stand out among a large peer group. Those who succeed are promoted to something like a “Staff Engineer”, then shoot for “Senior Engineer” and so on.
For some people the job title matters, but for others it’s the responsibility and autonomy that come with each promotion. The more senior you are, the more likely you are to be trusted to review code and give feedback to more junior peers. Perhaps you get to take on more interesting projects or are simply left alone to code more often.
At some point, usually when you hit the “Senior Engineer” stage, you’ll be confronted with the idea of some kind of leadership. At first it might be the opportunity to mentor junior engineers or lead a small project. It might even be in the form of a promotion to a Technical Lead where you’re given formal responsibility for leading projects and even people, without having them report to you in the management structure.
Both formal and informal Tech Lead and mentorship responsibilities are an opportunity for an engineer and their manager to get a sense of fit for managing other humans on the team. That’s a great thing, but it’s also where things often go wrong.
Two Paths, Not One
I recall being anxious to take on some kind of leadership role early in my career, likely before I was ready. Before I got any direct reports, I was given some project lead duties as well as a touch of mentoring. Both gave me a taste of what becoming a manager would be like, but just a small taste. In fact, many of the lessons I learned about taking a lead role didn’t translate well to management.
While mentoring helped hone coaching and support skills that paid off as a manager, the responsibilities of an informal tech lead actually drove me deeper into the technology. I found that even though I had to take a step back to see the bigger picture, I also had to get a solid understanding of the entire project at a technical level rather than just the component I was working on. Of course I didn’t realize this at the time, but in retrospect I was getting a taste of two potential future roles rather than preparing for one.
In time I’ve seen that great technical leads as well as software architects (the most senior of engineers) excel at many of the things I thought an engineering manager was supposed to do. They become experts in building great software as a team. That means writing great code, breaking down big problems into smaller ones, collaborating with other engineers, writing tests, knowing how much documentation is enough, and generally being aware of what they actually know and what they need to learn.
An engineering manager on the other hand doesn’t end up writing much code, and one that stays on the path to higher level leadership roles doesn’t write any meaningful code at all. By the time you hit the Director level*, your only hope of putting your headphones on and coding is at home on the weekend. Your job becomes ensuring that your team is effective in building software without building that software yourself.
Still, I think it’s important for an engineering manager to have been a solid software engineer. Not necessarily the top performer on the team, but someone who contributed to projects in a noticeable way and really “got” the process of writing software. Though you’ll move further away from the code as you progress on a management path, you’ll need to make strategic decisions that impact the development process and infrastructure. You’ll also command more respect from your team if you’ve been in the trenches. Many of the lessons learned as a tech lead apply in those respects.
*This isn’t necessary true at an early stage startup or very small company, but at even a mid-sized firm a Director tends to oversee multiple teams and numerous direct reports. VPs and CTOs? Forget about writing code!
Provide Options
The fact that many engineers are “promoted” into management despite the fact that they just want to be great engineers is the fault of management. Often there are no defined career paths within an engineering organization at all! People are promoted when it feels right, or a manager is afraid of losing someone. It’s a mess, and the only safe path of progression seems to be management.
In other organizations, management defines a career path but ignores the fact that not all engineers should progress into management roles. They’ll often promote to the Senior Engineer level and then start pushing some of those engineers into management roles either because they believe that it’s the right thing to do, or they simply need help managing a growing team. They might even promote an engineer to the role of “Software Architect”, but they don’t know what that means or what to do with that person in the long term.
Great engineering organizations acknowledge that not all engineers want to move into management and thus provide a defined path for individual contributors who excel and wish to take on more responsibility. Within such a track, roles like Technical Leads and Software Architects not only exist but are celebrated as a long term position and not a stepping stone to management.
I also believe that organizations should define and encourage lateral paths for engineers. Some may find that they don’t want to manage people, but rather projects. Some great Product Managers start out as engineers, so why not make that a clear option? I started in software engineering and eventually moved into data analytics and data engineering. I found that path on my own, but worked in an organization that supported the move.
Nothing is Permanent – Experiment!
Great engineering organizations not only provide multiple paths to career advancement, but they allow individuals to try out different roles with minimal risk.
Personally, I’ve accomplished this by giving an engineer the opportunity to mentor a new hire or lead a small project over the course of a few months. I made it clear to her and the team what the temporary role meant for all involved and kept reinforcing the responsibility through completion. During and after the project or mentorship ended, I spent a lot of time with the employee in one-on-ones providing feedback and asking questions – none more important than “what did you like and not like about it?”. No one is great at something the first time around, but few people feel indifferent about an experience like that. Were they relieved when it was over? Did they want to try it again or for a longer period of time?
Sometimes it’s not practical to give someone a taste of what life is like as a manager or team lead without formerly changing their role. For first time managers it’s important for them to have the respect of their team. That means that if you’re going to give someone that kind of responsibility, make it official and communicate it. Don’t label it temporary or a “test run”. As part of your team culture however, it’s valuable to make it OK for someone to manage for a while and then go back to an engineering role if it doesn’t work out.
By having clear paths for advancement for both individual contributors (ICs) and managers, it’s easier for an engineer to give management a shot, decide it’s not for them and then go back to the IC track. In fact, when it does happen you should be transparent with the team and celebrate the fact that you have a culture of experimentation and no single definition of career success.
Finally, don’t assume that anyone on the team will want to stay on one path for good. Though I find it common for people to give management a try and then go back to an engineering role, I’ve also seen a long-time engineer decide later in his career that he really did want to manage people. In general, the most supportive organizations provide career advancement that doesn’t look like a single, linear path.
Cover image by TukTukDesign from Pixabay
